Operating large platforms across an enterprise is a challenging task. Operations teams struggle to maintain consistency and compliance for infrastructures deployed by teams across the enterprise. Today’s development teams create apps consisting of dozens (or hundreds) of individual components or microservices running in container or serverless environments.

Each of these services is built to be independent and modular, so they can be changed without affecting others. One popular example is developing a complex website that requires data from different backends. Each individual development team works on one service at a time, so they can make changes faster, with less operational risk. 

However, it is important to recognize that there is a lot of complexity behind each of these simple services. For example, setting up a “simple” application (Fig. 1) that uses these microservices may require a long list of other services and configurations, such as the choice of computer implementation, DNS, load balancing, security, CI/CD pipeline, monitoring, etc. 

Fig. 1: A “simple” application

In addition to the platform teams, having development teams implement the actual functionalities is typical for larger companies. Developers work with the platform teams to define and create the infrastructure configurations and package everything for deployment. Every time the developers want to change something, the entire cycle has to be repeated with the platform team so they can maintain consistency and control over the services. One common approach many large companies take is building a shared service platform or an internal developer platform. Platform operators can define standards for security, software deployment, monitoring, and networks which gives them more control. Developers that use these platforms have a customized self-service interface optimized for code delivery. They can be more productive, rolling out software faster.

Controlling applications, implementing guardrails, and investing in developer productivity is nothing new. The problem is that existing solutions don’t find the right balance for companies with large development teams or quickly growing application portfolios using modern container and serverless architectures. There is a complete and flexible Infrastructure as a Service, giving developers the greatest possible freedom. But it also comes with a high level of responsibility. On the other hand, there is also the compartmentalized Platform as a Service. Here, the platform team makes all the decisions. This makes it easier for developers to run code, but it’s more difficult to innovate (Fig. 2).

Fig. 2: Advantages and disadvantages of PaaS and IaaS

Proton strikes a balance between operators’ need for control and developers’ need for flexibility. With Proton, platform teams can provide developers an easy way to deploy code using containers and serverless technologies, while also leveraging the management tools, governance, and visibility necessary for consistent standards and best practices.

Platform teams use Proton to create a stack that defines everything necessary for provisioning, deploying, and monitoring a service. Developers log in to the Proton console and use published Proton stacks to automate infrastructure provisioning and rapidly deploy application code. Instead of spending hours setting up infrastructure for each development team, platform or operations teams can centrally manage deployments without sacrificing productivity. When part of the stack needs to be updated, the platform team can use Proton to deploy updates to microservices that have outdated configurations.

Templates are the heart of Proton. They help define the stacks in which development teams will deploy their services and include the ability to connect infrastructure-as-code tools such as CloudFormation, Code Pipelines, and Observability. The next installment in this article series will take a closer look at the different templates. 

Develop state-of-the-art serverless applications?

Explore the Serverless Development Track

Learn more

What does a typical Proton workflow look like?

The diagram in Figure 3 shows a visualization of the main AWS Proton concepts discussed in the previous paragraph. It also provides an overview of what makes a simple AWS Proton workflow.

Fig. 3: Visual representation of a typical AWS Proton workflow

1. An administrator creates and registers an environment template in AWS Proton that defines the shared resources.
2. AWS Proton deploys one or more environments based on a previously created environment template.
3. An administrator creates and registers a service template with AWS Proton that defines the associated infrastructure, monitoring, and CI/CD resources, as well as compatible environment templates.
4. A developer selects a registered service template and provides a link to an existing source code repository.
5. AWS Proton provides the service with a CI/CD pipeline for the service instances.
6. AWS Proton deploys and manages the service and service instances that the application runs on – based on the selected service template. A service instance is an instantiation of the selected service templates in an environment for a single stage of a pipeline. For example, this can be the production environment. 

The operational view of things

Administrators – members of a platform team – create environment and service templates. A service template defines the common infrastructure used by multiple applications or resources. The service template defines the type of infrastructure required to deploy and maintain a single application or microservice in an environment. An AWS Proton service is an instantiation of a service template that typically includes several service instances and a pipeline. An AWS Proton service instance is the result of a service template in a particular environment. Team members can specify which environment templates are compatible with a particular service template. 

For AWS Proton, an environment represents a collection of shared resources and policies where Proton services are deployed. These can include any resources that are shared among Proton service instances, such as VPCs, clusters, shared load balancers, or API gateways.

An administrator can create an environment template and then register it with AWS Proton. AWS Proton provides the environment as defined in the environment template. One advantage is that Dev, Staging, and Prod environments can be created using the same environment template. For example, an environment named “development” might contain a VPC with private subnets and a restrictive access policy for all resources. The output of an environment can be used as inputs to services.

Before services can be created and rolled out with a service template, an environment must be provided in AWS Proton. When a service template is created, a list of compatible environment templates can be added. This lets developers choose between different options for the environments when creating a service from a service template.

Functionality for developers

Unlike other solutions, in Proton developers don’t need to be experts in the underlying infrastructure. They do not need to learn how to properly create and manage infrastructure as code templates like in CloudFormation. That’s completely removed from the development process. 

The only thing developers need to do is select a template, enter the necessary parameters within their administrator’s guidelines, and deploy their service. Proton takes care of the entire pipeline, providing the infrastructure and code in the new environment. Once a developer deploys their code with Proton, they will be able to see all running services (Fig. 4) and can easily tell if updates are available for the template. They can also easily view the status of their builds. If they need to make changes or redeploy with a new configuration, it’s all done right in Proton.

Fig. 4: An overview of deployed services

Security in Proton

With AWS Identity and Access Management (IAM), you can create IAM users and control who has access to which resources in an AWS account. IAM can be used with AWS Proton to control what users can do with AWS Proton. For example, you can control whether teams can create service templates or service instances, or if AWS Proton can make API calls to other services on their behalf.

Administrators own and manage resources that AWS Proton creates according to the environment and service templates. Users can add IAM service roles to their account, allowing AWS Proton to create resources on their behalf. When a service role is specified, AWS Proton uses the credentials of that role.

Another important aspect is patching: AWS Proton does not provide patches or updates for user-supplied code. Each user is responsible for updating and applying patches to their own deployed code. This includes the source code for services and applications running on AWS Proton as well as code deployed in the service and environment template bundles.

Users are responsible for updating and patching infrastructure resources in their environments and services. AWS Proton will not automatically update or patch resources. Because of this, it’s important to review the documentation for any architecture resources used. You should understand their respective patching policies.

For privacy reasons, it is recommended to set up individual IAM users and protect AWS account log-in information. This way, each user receives only the permissions they need to perform their tasks. The following measures are also recommended to protect data from unauthorized access:

• use multi-factor authentication (MFA) for each account
• Use SSL/TLS for communication with AWS resources (TLS 1.2 or higher)
• Set up API and user activity logging with AWS CloudTrail
• Leverage AWS encryption solutions with all standard security controls in AWS services.

All customer data is encrypted by default with an AWS Proton proprietary key in AWS Proton. When customer-owned and managed KMS keys are provided, then all customer data is encrypted using the customer-provided key.

Instead of embedding sensitive information in AWS CloudFormation templates and template bundles, it is recommended to use dynamic references in stack templates. Dynamic references provide a powerful, compact way to reference external values that are stored and managed in other services, such as the AWS Systems Manager Parameter Store or AWS Secrets Manager. When a dynamic reference is used, CloudFormation retrieves the value of the specified reference on-demand during stack and change set operations. It passes the value to the corresponding resource. However, CloudFormation never stores the actual reference value. AWS Secrets Manager helps securely encrypt, store, and retrieve credentials for databases and other services. The AWS Systems Manager Parameter Store is ideal for configuration data that needs to be stored securely in a hierarchical form.

Monitoring in AWS Proton

Monitoring is an important part of maintaining reliability, availability, and performance in AWS Proton. Right now, AWS Proton does not integrate with Amazon CloudWatch Logs or AWS Trusted Advisor. Administrators can configure and use CloudWatch to monitor other AWS services, which can be defined in the service and environment templates. Here is a list of monitoring tools that are available to monitor instances running in AWS Proton:

• Amazon CloudWatch monitors AWS resources and applications running in AWS in real time. It can be used to collect and track metrics, create custom dashboards, and set alarms. The alarms can be used as a notification, or as an automated action when a particular metric reaches a specific threshold. A popular example is the CPU usage or other metrics of Amazon EC2 instances. If they are needed, new instances start automatically.
• Amazon CloudWatch Logs provides monitoring, storage, and access to log files from Amazon EC2 Instances, CloudTrail, and other sources. CloudWatch Logs can monitor information in the log files and send notifications when certain thresholds are reached.
• AWS CloudTrail captures API calls and associated events made by or on behalf of an AWS account and provides the log files in a specified Amazon S3 bucket. This information can be used to identify which users and accounts made AWS calls. You can view the source IP address each call was made from, and when the calls were made.
• Amazon EventBridge is a serverless event bus service that makes it easy to connect applications to data from a variety of sources. EventBridge delivers a stream of real-time data from proprietary applications, software-as-a-service (SaaS) applications, and AWS services. It routes that data to destinations such as Lambda. For example, events that occur in services can be monitored and event-driven architectures can be built with this basic infrastructure.

Conclusion

AWS Proton is a new service for deploying container-based and serverless applications. It implements a popular setup used by large companies; administrators build a shared service platform that developers can use to roll out their applications. Administrators define templates that developers can use as a basis. Developers are only responsible for configuring the services. The actual implementation of the underlying platform is abstracted from them, which has the positive effect of allowing development teams to focus entirely on developing business-critical applications. AWS Proton supports a templating mechanism for developing custom templates. In the next article, we will take a closer look at the structure of these templates.